If body is null or invalid then it would break already in an earlier stage in the function which calls readAllBytes, because we call getReader() on the body which can throw an error. We expect in readAllFiles the generated Reader.

The only place we can error is when the reader is locked, so that read will throw. Other than that i dont see any code path possible to result in an error.

LOL, I actually found a bug in the sri code. I was wondering why setting the rejection handler in readLoop is not working.

What about if a large file is transmitted? Is fetch already buffering all of that in memory?

Only if you use one of those methods from the bodyMixing, like .text()``,.json() and so on. If you know that you expect a huge file you should stream it anyway.

For streams you have that logic directly in mainFetch called incrementalReadBody or so. There we use alot of magic like async generators.

Can you bench it somehow? I think it's a pretty good change if there's a significant improvement

@gurgunday

What I need is a way to count the generated Promises.

I use https://github.com/bengl/count-promises for that

@Uzlopak this now conflicts. can you use #4349 (comment) to count the promises?

@KhafraDev this seems to allocate way less promises than async/await combo.

My change reduces according to the "test" that the amount of promises is reduced by 1 per fetch call

1 less promise?

yes, 1 less promise. We create about 50 promises for a fetch call.

See the other PRs regarding removing async/promises. Maybe we can remove overall about 10 promises.

@KhafraDev can you take another look? I don't see how this is problematic

This needs a rebase, so that latest tests can run